ref: https://sysdig.com/blog/dockerfile-best-practices/
如果你常用到容器化、微服務架構,這些輕量化的架構當碰到問題時,背後的資安事件調查、報告、修復卻是影響甚鉅。然而,這些影響都可以透過「把安全意識擺在開發階段 (shifting left security)」來降低風險,而這篇文章就會講述 Dockerfile 的最佳實作手段有哪一些。
首先,我們會從幾個大面向來說明各種控制安全風險的細節,像是權限控管、降低攻擊層面、預防機敏資料洩漏,以及在發布 container image 時的注意事項。而你需要特別注意的是,其實 Dockerfile 也只是算是開發階段的一部份,所以這邊能提醒到的內容都屬於部署前(特別是開發階段)的準備。以下共提及 20 個你可以注意的重點,但因為篇幅較長,筆者將選出較重要的幾個來談談。
讓我們從「權限控管」說起:
Rootless container
根據報告結果顯示,有超過 58% 的 image 都是用 root 作為執行服務的使用者,所以在此也會建議透過 USER 參數來設定容器的預設使用者,同時,也可以利用執行環境/架構的設定來避免容器的預設使用者是 root。
Make executables owned by root and not writable
服務的 binary file 應該避免被任何人修改,容器的預設使用者只需要執行服務的權限,而不是擁有權。
至於「減少攻擊面」的部分:
Multistage builds小
在 image 的建立,可以透過 multistage build 來建立很多層 container,例如在第一層安裝編譯所需的套件,而第二層則只需安裝 runtime 所需的套件(如 openssl 等),再複製第一層所編譯出來的執行檔就可以了。其餘的因開發/編譯所安裝的套件皆不需要放在最後的 image,這樣同時也可以把 image 的大小縮小。
Distroless & Truested image
採用最小/最輕量化的 base image 來作為你打造 image 的基礎,同時使用可信任來源的 image,避免不小心在未知的情況引入好幾個潛在的安全威脅。(在原文中,sysdig 也使用了自身開發的工具來檢測 image 是否有安全問題,如果有需要也能參考看看)
而再來關於「機敏資訊」的部分:
Copy
當你在從你的開發環境複製檔案到 image 當中時,需要非常小心,因為你很可能一不小心就把你的密碼、開發環境的 token、API key 等資訊複製進去了。而且不要以為把 container 裡面的檔案刪掉就沒事了,別忘了 container image 是一層一層堆疊起來的,就算刪掉了,還是能在前面的 layer 裡面找到。
但如果還是有需要用到這些機敏資料,也可以考慮使用環境變數(docker run -e 引入),或是 Docker secret、Kubernetes secret 也能夠幫你引入這些參數。如果是設定檔的話,則可以用 mount 的方式來掛載到你的 container 裡面。
總而言之,你的 image 裡面不該有任何機敏資料、設定檔,開發服務時讓服務在 runtime 的時候可以接受來自環境變數的參數才是相對安全的。
其他的部分:
其實文章當中還有提到很多製作 image 的注意事項,像是在 deployment 階段,可能你部署的 latest 與實際的 latest 因時間差而不同。又或是在 image 裡面加上 health check,也才能做到狀況監測。
在容器化服務的時代,開發者不僅需要具備撰寫開發程式的能力,也要對於虛擬化環境有足夠的理解,否則,在對架構不熟的情況就將服務部署上去,或把 image 推送到公開的 registry,都可能造成重要的資料外洩與潛在的資安危機。
「docker base image」的推薦目錄:
- 關於docker base image 在 矽谷牛的耕田筆記 Facebook 的最佳解答
- 關於docker base image 在 矽谷牛的耕田筆記 Facebook 的精選貼文
- 關於docker base image 在 矽谷牛的耕田筆記 Facebook 的精選貼文
- 關於docker base image 在 phusion/baseimage-docker: A minimal Ubuntu base image ... 的評價
- 關於docker base image 在 Baseimage-docker: A minimal Ubuntu base image modified ... 的評價
- 關於docker base image 在 Why do you need a base image with Docker? - Stack Overflow 的評價
- 關於docker base image 在 learn what is base image in dockerfile 的評價
docker base image 在 矽谷牛的耕田筆記 Facebook 的精選貼文
本篇文章是個經驗分享文,作者分享使用 Docker 作為開發環境時值得注意的 Best practices,透過這些經驗分享希望能夠讓開發者少走一些冤枉路。
原文提出了 15 個經驗談,這邊幫大家節錄幾個,有興趣的可以點選原文瞭解更多!
1. One thing at a time
2. Be ephemeral
3. Utilize .dockerignore
4. Less is more
5. Secrets should be secret
6. PID 1 is your birth right
7. Share and Care
8. Vulnerability Scan
9. Tag like you mean it
10. Permissions are costly
11. Source of Truth
12. Always official
13. Don’t include debug
14. Use entry point script smartly
15. Size does matter
One thing at a time
建置 Image 的時候專注做好一件事情,每個 Image 應該有一個專心要解決的問題,譬如一個應用程式,一個小工具等。對於 Nginx 這類型的 Image 來說,應該沒有人會期望於裡面看到有 Apache 的應用程式吧?
Be ephemeral
這個主要探討的是該 Image 本身建置時應該要以 stateless 的概念去處理,未來不論是透過 docker 或是 Kubernetes 來管理部署時,Contaienr 都很有機會被重啟,每次的重啟都意味該容器是重新啟動。所以千萬不要讓你的 Image 變成多次重啟會導致應用程式出問題的形式,任何的這類型資料應該都要透過外部取得,不要塞到你的 Image 內
Utilize .dockerignore
善用 .dockerignore 這個檔案來將不必要的檔案從 build 過程給排除,使用方法與 .gitignore 類似。透過這個檔案的設定可以避免 docker build 的時候不會把一些過大或是完全不需要的檔案都送給 docker daemon,不當浪費時間也浪費空間。
Less is more
避免安裝任何無關或是非必要的套件到你的 image 中,特別是那些 "nice to have" 的理由。
註: 我個人是滿討厭把 Image 弄得很乾淨的,除錯什麼工具都沒有,連 ash/sh/busybox/bash 都沒有的 image 更是我討厭中的排行榜冠軍
Secrets should be secret
任何機密資訊都應該要於運行期間動態載入,而不是建置期間塞入。請使用其他工具譬如 Vault 來管理這些機密資訊,並且執行期間讓 Container 能夠存取到正確的值。
PID 1 is your birth right
Linux 環境下會使用 SIGTERN, SIGKILL 等相關的 Singal 來戳你的應用程式,請確保你運行的應用程式要能夠攔截這些訊號來處理並完成有效的 Graceful shutdown.
Share and Care
如果環境中有多個 Image 彼此有共享相同的工具與功能,與其每個 Image 都單獨建置維護不如建置一個 Base Image,接者讓所有要使用的 image 去載入使用即可。
透過這種方式可以讓整體的維護性與管理性更為簡單,每個 image 可以減少重複的程式碼,同時要升級時只要針對 base Image 處理即可。
https://medium.com/pradpoddar/avoid-costly-mistakes-using-advanced-docker-development-best-practices-acd812784109
docker base image 在 矽谷牛的耕田筆記 Facebook 的精選貼文
熟悉 Dockerfile 的讀者一定都熟悉撰寫 Dockerfile 的過程,其中很重要的一個環節是選擇一個 Base Image。
本篇文章的標題列舉的大量的 base image,包含了 alpine, slim, stretch ... 等,對於使用者來說,到底這些 image 差異是什麼,選擇上有什麼需要注意的
舉例來說, 當 image tag 結尾是 -slim 時,通常代表的是完整版本的相反體,也就是 只有安裝滿足應用所需要的依賴性套件而已,其餘用不到的都沒有安裝。
透過這方式整個 image 的大小也會相對比較小,畢竟用不到的軟體都沒有被安裝
作者提到說當使用 slim image 出現無法解釋的問題時,可以先嘗試使用完整版本的 image 先行除錯看看。
至於 Apline 的版本,則是基於 Alpine Linux Project 這個作業系統所發展的版本,其因為簡單且 image size 不大而廣受使用。但是使用上也是有很多要注意的地方,譬如一些相容性問題,作者提到 python 內就有 Debian/Alpine 彼此不相容的地方,導致除錯時會很生氣。
最後作者還提到選擇 image 的一些想法
1. 沒有硬碟空間的考量,要趕快上線使用且沒有時間慢慢測試,就直接使用知名的完整image,如 debian 等
2. 有硬碟空間考量且很明確要使用的工具是什麼,可以考慮使用 -slim 的版本
...等
原文:
https://medium.com/swlh/alpine-slim-stretch-buster-jessie-bullseye-bookworm-what-are-the-differences-in-docker-62171ed4531d
docker base image 在 Baseimage-docker: A minimal Ubuntu base image modified ... 的推薦與評價
YOUR DOCKER IMAGE MIGHT BE BROKEN without you knowing it. Learn the right way to build your Dockerfile. ... <看更多>
docker base image 在 phusion/baseimage-docker: A minimal Ubuntu base image ... 的推薦與評價
Baseimage -docker is a special Docker image that is configured for correct use within Docker containers. It is Ubuntu, plus:. ... <看更多>